Struts与MVC模式

在我前面的那篇<<再战MVC（二）>>最后也说到了：MVC本身就是一个非常复杂的系统，所以采用MVC实现Web应用时，如果采用现成的MVC框架，在此之下进行开发，能够达到事半功倍的效果。因为如果说要想在一些有限的时间里构造出来一个正确并且是可维护性的应用程序，我们必须有一个好的工具或者框架来建立表现层， 纵观目前在开源社区中针对Web表现层的开源框架webwork,struts等，struts是一个不错的选择，因为Struts有完整的文档并且相对来讲比较简单。

对MVC体系结构还有一些常用设计模式有了一定的认识之后，回过头来再次看那本Struts开发者写的<<struts in action>>，特别是发现第二章的“研究Struts体系结构”能让你看了对MVC模式以及Struts的体系结构有更深刻的理解，个人感觉这一章是整本书的精华的地方。

MVC 通常表示为3个互相连接的组件

上图是典型的MVC模式，经常被表示为：一个互相连接的三角形。对于一个基于Web的应用程序而言，是很难维护该三角形的“改变通知 (state query/change notification)”这一部分。这些东西在所有资源都在一台服务器上，而且客户端保持一个开放连接的情况下工作得非常好。如果资源分布在不同的服务器上，并且客户端不能维护一个开放的连接情况下，工作的并不理想。许多分布式系统架构，包括web应用，在视图进行状态查询的概念时退缩了。针对这种不同，绝大多数情况是入分层的概念来设计的，层内的对象可以和同一层或者相邻层的对象进行通信。在一个复杂应用中，这可以在添加组件时，防止依赖关系呈指数增长。对于分布式应用程序而言，“分层“模式是设计中的核心模式。

 

  

 

正如上图上所示，使用平面设计而不是传统的MVC设计方式。控制层处于表现层（视图）和应用程序逻辑（模式）之间。

 

从MVC 上下文中，引入层模式将状态改变和状态查询的职责加于控制器之上，并伴随 着改变通知。

 

每一个模块的主要职责并没有改变。流程有轻微改变，即查询状态和改变通知都必须通过控制器。另一个改变是当视图（表现层）生成动态内容时，它使用由控制器提供的数据而不是直接由模式提供的数据。所以说这样的改变使得视图更加和模式无关了，即由控制器来选择数据并显示数据的视图，这样就从根本上去除了View 和 Model的耦合。